Table of Contents
This chapter provides information on configuring access to files over the Network File System (NFS) and Common Internet File System (CIFS) protocols. It also discusses setting up security for file access by using mechanisms such as Kerberos and export rule sets.
After you create a virtual server, you can configure it to provide NFS access, CIFS access, or both. To enable NFS access, you enable a virtual server for NFS and optionally modify its configuration to use a Kerberos realm for secure authentication. To enable CIFS access, you must create a CIFS domain, enable a virtual server for CIFS access, create one or more CIFS shares, and possibly enable a CIFS account to have superuser privileges. You can set up export rules to manage access to data based on client protocol and authentication type. If you enable both NFS and CIFS access, you can also set up name mappings between UNIX (NFS) and Windows (CIFS) users. These topics are discussed in the following sections.
Data ONTAP 10.0 supports NFS v2 and v3 over UDP and TCP. NFS access depends on an NIS domain, as described in Chapter 9, Managing Services.
Kerberos is a network authentication protocol developed at the Massachusetts Institute of Technology. Kerberos uses encryption keys to provide authentication for client/server applications. Authentication provides verification of a user's or process's identity to a server. In the Data ONTAP 10.0 environment, Kerberos is used to provide authentication between virtual servers and NFS and CIFS clients. For more information about Kerberos, see web.mit.edu/kerberos/www/.
SpinAuth is a lightweight authentication mechanism that improves the security of NFS requests, which are otherwise protected only by the AUTH_SYS mechanism. The AUTH_SYS mechanism, which is standard with NFS, does not provide secure authentication of client requests; NFS Kerberos provides strong authentication of client requests but has few available client programs. SpinAuth enables users to authenticate by using Kerberos and pass the authenticated identity to a node, which then caches the credentials for future requests from the users' clients.
The lifetime of the SpinAuth credential is the same as the lifetime of the Kerberos credential.
If you are accustomed to administering NFS on systems running Data ONTAP 7G or earlier, note the following differences between Data ONTAP 10.0 and Data ONTAP 7G or earlier:
Data ONTAP 10.0 does not support NFS v4.
There is no equivalent in Data ONTAP 10.0 to the /etc/exports file on Data ONTAP 7G or earlier systems. Instead, use the protocol exportruleset commands to set up export rules.
Exporting a subdirectory of a volume, or "sub-volume exporting," is possible but not recommended. Instead, NetApp recommends that you set up a separate volume for the directory that you would otherwise export as a subdirectory.
Temporary exports cannot be defined on a Data ONTAP 10.0 system. Any export defined on a Data ONTAP 10.0 system is persistent across system restarts.
Because Data ONTAP 10.0 has a global namespace, there is no Data ONTAP 10.0 equivalent to the actual= syntax in Data ONTAP 7G or earlier. You can use symbolic links to maintain compatibility with existing client-side mount tables.path
Kerberos 5 integrity (krb5i) and Kerberos 5 privacy (krb5p) are not supported in Data ONTAP 10.0.
There is no equivalent in Data ONTAP 10.0 to the showmount command in Data ONTAP 7G or earlier, which displays a list of clients that have outstanding NFS mounts on an NFS server.
Data ONTAP 10.0 does not support fencing. However, an export rule that blocks a specific client's or clients' access to a volume provides the same functionality as fencing.
Windows network clients that need to use file server resources must be able to locate the file server on the network. CIFS does this with NetBIOS names. A NetBIOS name is a case-insensitive name, with a maximum length of 16 characters, that uniquely identifies a host on a subnetwork. You must provide a unique NetBIOS name for each of the CIFS-enabled virtual servers you define. This name is used when CIFS clients connect to the file server.
The Windows Internet Name Service (WINS) was created as an extension to the original NetBIOS naming specification. WINS performs the same basic function as a DNS server; that is, it accepts name registrations from hosts that must register or publish their network services. It resolves names into IP addresses for hosts that need to access those resources. WINS servers also communicate with each other and exchange host information so that hosts in one subnet can be known in another subnet. WINS does, however, complicate the name registration process for hosts.
The NetBIOS protocol partitions groups of servers into multiple subnets, thus requiring the client to know the IP address of the host if it exists on another subnet. The WINS server provides ways to look up server IP addresses for servers that are on a separate subnet. The NetBIOS node types determine the process by which the original NetBIOS protocol and WINS are used to locate a server.
Four different mechanisms are currently in place to register NetBIOS host names on a network. These are described as follows:
The B or Broadcast NetBIOS Node Type is a purely broadcast mechanism in which the host announces its name to the subnet.
The P or Peer NetBIOS Node Type is a WINS mechanism in which the host is configured with the name of a WINS server and informs the WINS server of its intent to use a NetBIOS host name.
The H or Hybrid NetBIOS Node Type is a mixed-mode announcement mechanism in which the host first contacts the WINS server and negotiates the use of its NetBIOS name and then broadcasts its name to the local subnet. This type is not supported by the Data ONTAP 10.0 system.
The M or Microsoft NetBIOS Node Type is another mixed-mode announcement mechanism, in which the host first broadcasts its name to the local subnet and then contacts a WINS server and negotiates for use of its NetBIOS host name.
The default NetBIOS Node Type is M.
A WINS Server IP address is required if any virtual servers are using the M, H, or P NetBIOS node types. Without a WINS Server IP address, virtual servers can have only a B NetBIOS node type.
See the Windows documentation for further information about WINS and NetBIOS.
Each CIFS virtual server must participate in the Windows NT Domain Security model and have a corresponding account on the Windows Primary Domain Controller for the domain it participates in. Also, to prevent users of one CIFS virtual server in one domain from seeing another CIFS virtual server in another domain, NetBIOS name announcements must be limited to the subnet in which the virtual server is located. To accomplish this, NetBIOS name announcements are limited by the subnet mask that is specified in the management interface when a virtual interface is created.
To define a CIFS domain, you need to have the following information available:
Domain name
Name and IP address of a primary domain controller
IP address of a WINS server (optional but recommended)
Names and IP addresses of up to four backup domain controllers (optional)
CIFS requires a separate license; contact your sales or support representative for details.
The Data ONTAP 10.0 architecture enables concurrent access to files via the NFS and CIFS protocols and the use of the Kerberos authentication protocol. Although all of these protocols have the concept of a principal (a user or group), they use incompatible formats for storing principal information. CIFS stores user and group information on a Windows Domain Controller (primary or backup) by using either NetLanMan (NTLM) or Kerberos authentication. NFS stores user and group information in the Network Information System (NIS), with few rules for authentication. NFS supports a single NIS domain per file server, whereas CIFS supports a network of cooperating domains. Kerberos maintains its own database, one per Kerberos realm. Name mappings provide a level of compatibility among these models.
Name mappings are applied in the order in which they appear in the priority list; for example, a name mapping that occurs at position 2 in the priority list is applied before a name mapping that occurs at position 3. Each mapping direction (Kerberos to UNIX, Windows to UNIX, and UNIX to Windows) has its own priority list.
A Data ONTAP 10.0 system has a maximum of 256 name mappings.
NFS and CIFS use incompatible models to internally represent principal information. Data ONTAP 10.0 bases its conversions on user and group names. A typical CIFS user might be ENG\jones, where ENG in the domain or workgroup name and jones is the login name of a user. An NFS user name might be jones. Note that CIFS names include a domain, but NFS names do not. Because NFS supports only a single domain per file server, the domain name is implied. A Kerberos user might be jones/myserver@EXAMPLE.COM, where jones is the login name of a user (in Kerberos terms, the primary), myserver is a hostname or other information that qualifies the primary (in Kerberos terms, the instance), and EXAMPLE.COM is a logical network (in Kerberos terms, the realm)) served by a single Kerberos database and one or more Key Distribution Centers (KDCs). A KDC is a server that issues Kerberos tickets. Kerberos realms are listed in uppercase.
Data ONTAP 10.0 can translate CIFS principals and Kerberos principals to NIS principals. It does this by translating a CIFS or Kerberos principal's internal representation into a name, matching the name against a set of rules, and, if a match is found, rewriting the name by using a substitution template and converting the rewritten name into NFS's internal principal representation. A similar sequence is used to convert NIS principals into CIFS principals when sending replies to CIFS clients. Converting NIS principals into Kerberos principals is not required.
Only CIFS and Kerberos principals are subject to translation. NIS principals are the canonical representation.
The Data ONTAP 10.0 system keeps an NIS domain and a set of conversion rules for each virtual server. Each rule consists of two pieces: a pattern and a replacement. Conversions start at the beginning of the appropriate list and perform a substitution based on the first matching rule. The pattern is a UNIX-style regular expression. The replacement is a string containing escape sequences representing subexpressions from the pattern, as in the UNIX sed program.
Regular expressions are case-insensitive when mapping from Windows to UNIX. However, they are case-sensitive for Kerberos-to-UNIX and UNIX-to-Windows mappings.
As an example, the following rule converts the CIFS user named jones in the domain named ENG into the UNIX user named jones.
| Pattern | Replacement |
|---|---|
| ENG\\jones | jones |
Note that the backslash is a special character in regular expressions and must be escaped with another backslash.
The caret (^), underscore (_), and ampersand (&) characters can be used as prefixes for digits in replacement patterns. These characters specify uppercase, lowercase, and initial-case transformations, respectively. For instance:
If the initial pattern is (.+) and the replacement pattern is \1, then the string jOe is mapped to jOe (no change).
If the initial pattern is (.+) and the replacement pattern is \_1, then the string jOe is mapped to joe.
If the initial pattern is (.+) and the replacement pattern is \^1, then the string jOe is mapped to JOE.
If the initial pattern is (.+) and the replacement pattern is \&1, then the string jOe is mapped to Joe.
If the character following a backslash-underscore (\_), backslash-caret (\^), or backslash-ampersand (\&) sequence is not a digit, then the character following the backslash is used verbatim.
The following example converts any Windows user in the CIFS domain named ENG into a UNIX user with the same name in NIS.
| Pattern | Replacement |
|---|---|
| ENG\\(.+) | \1 |
The double backslash (\\) matches a single backslash. The parentheses denote a subexpression but do not match any characters themselves. The period matches any single character. The asterisk matches zero or more of the previous expression. In this example, you are matching ENG\ followed by one or more of any character. In the replacement, \1 refers to whatever the first subexpression matched. Assuming the CIFS user ENG\jones, the replacement evaluates to jones; that is, the portion of the name following ENG\.
If you are using the CLI, you must delimit all regular expressions with double quotation marks ("). For instance, to enter the regular expression (.+) in the CLI, type "(.+)" at the command prompt. Quotation marks are not required in the Web UI.
For further information about regular expressions, see your UNIX system administration documentation, the online UNIX documentation for sed or regex, or Mastering Regular Expressions, published by O'Reilly and Associates.
For Windows-to-UNIX translation, credentials supplied by a client are subject to translation before being processed by the Data ONTAP 10.0 file system. File attributes (file owner and group) are subject to translation going in both directions. ACL entries are subject to translation of CIFS to NFS and NFS to CIFS.
File protection decisions take place on the Data ONTAP 10.0 file system after any translations have occurred. All Data ONTAP 10.0 users and groups are qualified by a domain. Domain zero is defined to represent the NIS namespace for the current virtual server. Other domain values map to one of the known CIFS domains.
Each virtual server is configured with an NIS domain. When a CIFS primary group cannot be mapped, or when NFS receives the attributes of a file whose domain is nonzero, the NIS nobody user or group (UID or GID -2) is substituted.
The translation process between Windows and UNIX proceeds as follows:
When a credential is received from an NFS client, the Data ONTAP 10.0 system uses the NFS user and group in domain 0 (zero).
When a credential is received from a CIFS client:
If both the user ID (UID) and primary group are translated, translations are used.
If only the user translates, the Data ONTAP 10.0 system uses the translated user and replaces the primary group with the NIS group nobody (-2) in the NFS domain (domain 0).
If the user does not translate, the Data ONTAP 10.0 system uses the CIFS user and group. The Data ONTAP 10.0 system uses the CIFS user and group with a nonzero domain. The nonzero domain corresponds to the appropriate CIFS domain.
For each ACL entry, the Data ONTAP 10.0 system uses a translation if one is available; otherwise it sends a CIFS principal; that is, a nonzero domain.
When file attributes that are destined for a CIFS client are received:
If the file's owning domain is nonzero, Data ONTAP 10.0 assumes the user and group are already from a CIFS domain and does not attempt a mapping.
If the file's owning user and group map to CIFS, Data ONTAP 10.0 uses the mappings.
If the file's owning user or group does not have a mapping, Data ONTAP 10.0 translates them to local IDs that refer to the virtual server.
For users and groups in ACLs, Data ONTAP 10.0 translates them if possible; otherwise it translates them to local IDs that refer to the virtual server.
When file attributes that are destined for an NFS client are received:
If the domain is zero, Data ONTAP 10.0 passes the user and group unchanged.
If NFS sees a domain other than zero, it sets the user to nobody (-2) and the group to nobody (-2).
The following rules and recommendations apply to Windows-to-UNIX mappings:
A file's attributes specify a single domain, shared by the owning user and group. Thus, the file's user and group must come from the same domain.
NFS credentials can never map to nonzero Data ONTAP 10.0 domains. Thus, an NFS user can never get an untranslatable CIFS user's file access permissions.
There is no facility for adjusting file ownerships after the translation rules have been adjusted. Changes to the translation rules can cause preexisting files now owned by invalid users—that is, CIFS users that are now translated to NIS users—to be inaccessible. For this reason, it is important to set up any desired translations before users begin creating files.
Generally, all CIFS users are member of the your_domain\Domain Users group. It is convenient to create an NIS group (for instance, cifs_user) that maps to and from Domain Users.
If an NFS user is logged in as UID 0 (root) without Kerberos authentication, the user is mapped to -2/-2 (nobody/nobody). Because Kerberos-enabled clients must be explicitly set up to map to root, this does not affect Kerberos-enabled clients.
Export rule sets enable you to restrict access to volumes to clients that match specific IP addresses and specific authentication types. Each volume is associated with exactly one rule set. Each rule set is identified by a unique name and a unique numeric ID. A Data ONTAP 10.0 cluster can contain up to 1,024 rule sets. Each cluster has at least one rule set with ID 0, which contains no rules. This rule set cannot be deleted, although it can be renamed or modified.
A newly installed or upgraded cluster contains only the default rule set. Each volume on a new or upgraded cluster is associated with no rule set, and the default rule set is applied to it; however, if viewed with the volume show command, the associated rule set is displayed as none. In a new cluster, the default rule set is associated with new volumes, but you can also explicitly associate new volumes with the rule set named none. The primary difference between allowing a new volume to have the default rule set applied to it and applying the rule set named none to it is the inheritance or overriding of rule sets when the volume is mounted or has its export rule set reset.
Rule sets consist of individual rules. A rule set can contain a large number of rules (approximately 4,000). Each rule specifies the number of mask bits in the client IP address that must be matched for that rule to apply to a particular client request. The rule also specifies the authentication types that are required for both read-only and read-write operations. To have any access to a volume, matching clients must authenticate with the authentication type specified by the read-only rule. To have write access to the volume, matching clients must authenticate with the authentication type specified by the read-write rule. If a client makes an access request that is not permitted by the applicable rule set, the request fails with a permission-denied message. If a client IP address does not match any rule in the volume's rule set, then access is denied, except in the special case in which the rule set is empty (contains zero rules). If a rule set is empty, then all accesses are implicitly permitted.
When using export rule sets, you can specify a netgroup name instead of an IP address and mask bits to match clients to an export rule. A netgroup is a named collection of arbitrary IP addresses that is stored in an NIS map.
Rules are evaluated in the order in which they appear in the rule set. You can reorder rules in a rule set.
You can modify a rule set dynamically on a running Data ONTAP 10.0 system; however, changes can take up to two minutes to propagate and take effect.
Export rule sets are not specific to any one virtual server; however, because each virtual server has an independent NIS domain and the set of IP addresses that a netgroup matches is dependent on NIS, each netgroup-based rule can match different clients on different virtual servers that have different NIS domains.